Method and apparatus for identification and transfer in internet protocol multimedia subsystem collaborative sessions

ABSTRACT

A method and apparatus are described for performing Internet Protocol (IP) Multimedia Subsystem (IMS) operation. A wireless transmit/receive unit (WTRU) registers an IMS service priority with an IMS network. The IMS service priority indicates the WTRU&#39;s priority in receiving IMS services. The WTRU may receive an IMS service from the IMS network based on the WTRU&#39;s IMS service priority. The IMS service priority may be indicated using a priority value and the WTRU may use Session Initiation Protocol (SIP) messaging to signal with the IMS network. The WTRU may register the service priority value using a q-value parameter in an SIP Contact field header. The WTRU may also register a public user identity with the IMS network and the public user identity may be shared with other IMS-capable WTRUs.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. provisional application No.61/310,486, filed on Mar. 4, 2010; and U.S. provisional application No.61/317,988, filed on Mar. 26, 2010, the contents of which are herebyincorporated by reference herein.

FIELD OF INVENTION

This application is related to communications.

BACKGROUND

Internet Protocol (IP) Multimedia Subsystem (IMS) is an architecturalframework for providing multimedia services across a variety of accessplatforms. IMS facilitates multimedia service creation and deploymentbased on Internet protocols allowing IMS subscribers to accesspersonalized interactive, multimedia services, on any device, andanywhere. IMS is access-agnostic, whereby service delivery isindependent of the underlying access platform and the use of Internetprotocols in IMS allows for interoperability among the access platforms.IMS also leads to savings in network infrastructure, administration andmanagement. Further, IMS allows for the migration of Circuit Switched(CS) services like voice telephony to the Packet Switched (PS) domain byusing separate control and bearer functions and featuring an overlayservice delivery network on top of a packet switch networkinfrastructure.

In IMS, media sessions may be directed to any one of multipleIMS-capable devices communicating via an IMS network. An IMS network maytherefore face decisions regarding the routing of media sessions and howto signal such determinations. Additionally, multiple IMS-capabledevices may be served by multiple IMS networks and the networks'functional entities, whereby the various networks may face decisionsregarding the management of IMS sessions that they may seek to resolvewithout creating unnecessary signaling traffic.

It is therefore desirable to have a method and apparatus for IMS-capabledevices to indicate routing preferences to an IMS network. It is furtherdesirable to have a method and apparatus for IMS networks andIMS-capable devices to efficiently identify and transfer their roles.

SUMMARY

A method and apparatus are described for performing Internet Protocol(IP) Multimedia Subsystem (IMS) operation. A wireless transmit/receiveunit (WTRU) registers an IMS service priority with an IMS network. TheIMS service priority indicates the WTRU's priority in receiving IMSservices. The WTRU may receive an IMS service from the IMS network basedon the WTRU's IMS service priority. The IMS service priority may beindicated using a priority value and the WTRU may use Session InitiationProtocol (SIP) messaging to signal with the IMS network. The WTRU mayregister the service priority value using a q-value parameter in an SIPContact field header. The WTRU may also register a public user identitywith the IMS network and the public user identity may be shared withother IMS-capable WTRUs.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding may be had from the following description,given by way of example in conjunction with the accompanying drawingswherein:

FIG. 1A is a system diagram of an example communications system in whichone or more disclosed embodiments may be implemented;

FIG. 1B is a system diagram of an example wireless transmit/receive unit(WTRU) that may be used within the communications system illustrated inFIG. 1A;

FIG. 1C is a system diagram of an example radio access network and anexample core network that may be used within the communications systemillustrated in FIG. 1A;

FIG. 2A shows a WTRU in an IMS session with a remote party;

FIG. 2B shows functional entities within an IMS network;

FIG. 2C shows multiple WTRUs served by a single IMS network in acollaborative IMS session;

FIG. 3 shows an information flow for WTRU registration and IMS sessionrouting in accordance with a described embodiment; and

FIG. 4 shows multiple WTRUs served by multiple IMS networks in a IMScollaborative session;

FIG. 5 shows an information flow for anchor Service Centralization andContinuity Application Server (SCC AS) identification and transferringin accordance with a described embodiment; and

FIG. 6 shows an information flow for the transfer of IMS collaborativesession control.

DETAILED DESCRIPTION

FIG. 1A is a diagram of an example communications system 100 in whichone or more disclosed embodiments may be implemented. The communicationssystem 100 may be a multiple access system that provides content, suchas voice, data, video, messaging, broadcast, etc., to multiple wirelessusers. The communications system 100 may enable multiple wireless usersto access such content through the sharing of system resources,including wireless bandwidth. For example, the communications systems100 may employ one or more channel access methods, such as code divisionmultiple access (CDMA), time division multiple access (TDMA), frequencydivision multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrierFDMA (SC-FDMA), and the like.

As shown in FIG. 1A, the communications system 100 may include wirelesstransmit/receive units (WTRUs) 102 a, 102 b, 102 c, 102 d, a radioaccess network (RAN) 104, a core network 106, a public switchedtelephone network (PSTN) 108, the Internet 110, and other networks 112,though it will be appreciated that the disclosed embodiments contemplateany number of WTRUs, base stations, networks, and/or network elements.Each of the WTRUs 102 a, 102 b, 102 c, 102 d may be any type of deviceconfigured to operate and/or communicate in a wireless environment. Byway of example, the WTRUs 102 a, 102 b, 102 c, 102 d may be configuredto transmit and/or receive wireless signals and may include userequipment (UE), a mobile station, a fixed or mobile subscriber unit, apager, a cellular telephone, a personal digital assistant (PDA), asmartphone, a laptop, a netbook, a personal computer, a wireless sensor,consumer electronics, and the like.

The communications systems 100 may also include a base station 114 a anda base station 114 b. Each of the base stations 114 a, 114 b may be anytype of device configured to wirelessly interface with at least one ofthe WTRUs 102 a, 102 b, 102 c, 102 d to facilitate access to one or morecommunication networks, such as the core network 106, the Internet 110,and/or the networks 112. By way of example, the base stations 114 a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a HomeNode B, a Home eNode B, a site controller, an access point (AP), awireless router, and the like. While the base stations 114 a, 114 b areeach depicted as a single element, it will be appreciated that the basestations 114 a, 114 b may include any number of interconnected basestations and/or network elements.

The base station 114 a may be part of the RAN 104, which may alsoinclude other base stations and/or network elements (not shown), such asa base station controller (BSC), a radio network controller (RNC), relaynodes, etc. The base station 114 a and/or the base station 114 b may beconfigured to transmit and/or receive wireless signals within aparticular geographic region, which may be referred to as a cell (notshown). The cell may further be divided into cell sectors. For example,the cell associated with the base station 114 a may be divided intothree sectors. Thus, in one embodiment, the base station 114 a mayinclude three transceivers, i.e., one for each sector of the cell. Inanother embodiment, the base station 114 a may employ multiple-inputmultiple output (MIMO) technology and, therefore, may utilize multipletransceivers for each sector of the cell.

The base stations 114 a, 114 b may communicate with one or more of theWTRUs 102 a, 102 b, 102 c, 102 d over an air interface 116, which may beany suitable wireless communication link (e.g., radio frequency (RF),microwave, infrared (IR), ultraviolet (UV), visible light, etc.). Theair interface 116 may be established using any suitable radio accesstechnology (RAT).

More specifically, as noted above, the communications system 100 may bea multiple access system and may employ one or more channel accessschemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. Forexample, the base station 114 a in the RAN 104 and the WTRUs 102 a, 102b, 102 c may implement a radio technology such as Universal MobileTelecommunications System (UMTS) Terrestrial Radio Access (UTRA), whichmay establish the air interface 116 using wideband CDMA (WCDMA). WCDMAmay include communication protocols such as High-Speed Packet Access(HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed DownlinkPacket Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

In another embodiment, the base station 114 a and the WTRUs 102 a, 102b, 102 c may implement a radio technology such as Evolved UMTSTerrestrial Radio Access (E-UTRA), which may establish the air interface116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

In other embodiments, the base station 114 a and the WTRUs 102 a, 102 b,102 c may implement radio technologies such as IEEE 802.16 (i.e.,Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000,CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), InterimStandard 95 (IS-95), Interim Standard 856 (IS-856), Global System forMobile communications (GSM), Enhanced Data rates for GSM Evolution(EDGE), GSM EDGE (GERAN), and the like.

The base station 114 b in FIG. 1A may be a wireless router, Home Node B,Home eNode B, or access point, for example, and may utilize any suitableRAT for facilitating wireless connectivity in a localized area, such asa place of business, a home, a vehicle, a campus, and the like. In oneembodiment, the base station 114 b and the WTRUs 102 c, 102 d mayimplement a radio technology such as IEEE 802.11 to establish a wirelesslocal area network (WLAN). In another embodiment, the base station 114 band the WTRUs 102 c, 102 d may implement a radio technology such as IEEE802.15 to establish a wireless personal area network (WPAN). In yetanother embodiment, the base station 114 b and the WTRUs 102 c, 102 dmay utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE,LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A,the base station 114 b may have a direct connection to the Internet 110.Thus, the base station 114 b may not be required to access the Internet110 via the core network 106.

The RAN 104 may be in communication with the core network 106, which maybe any type of network configured to provide voice, data, applications,and/or voice over internet protocol (VoIP) services to one or more ofthe WTRUs 102 a, 102 b, 102 c, 102 d. For example, the core network 106may provide call control, billing services, mobile location-basedservices, pre-paid calling, Internet connectivity, video distribution,etc., and/or perform high-level security functions, such as userauthentication. Although not shown in FIG. 1A, it will be appreciatedthat the RAN 104 and/or the core network 106 may be in direct orindirect communication with other RANs that employ the same RAT as theRAN 104 or a different RAT. For example, in addition to being connectedto the RAN 104, which may be utilizing an E-UTRA radio technology, thecore network 106 may also be in communication with another RAN (notshown) employing a GSM radio technology.

The core network 106 may also serve as a gateway for the WTRUs 102 a,102 b, 102 c, 102 d to access the PSTN 108, the Internet 110, and/orother networks 112. The PSTN 108 may include circuit-switched telephonenetworks that provide plain old telephone service (POTS). The Internet110 may include a global system of interconnected computer networks anddevices that use common communication protocols, such as thetransmission control protocol (TCP), user datagram protocol (UDP) andthe internet protocol (IP) in the TCP/IP internet protocol suite. Thenetworks 112 may include wired or wireless communications networks ownedand/or operated by other service providers. For example, the networks112 may include another core network connected to one or more RANs,which may employ the same RAT as the RAN 104 or a different RAT.

Some or all of the WTRUs 102 a, 102 b, 102 c, 102 d in thecommunications system 100 may include multi-mode capabilities, i.e., theWTRUs 102 a, 102 b, 102 c, 102 d may include multiple transceivers forcommunicating with different wireless networks over different wirelesslinks. For example, the WTRU 102 c shown in FIG. 1A may be configured tocommunicate with the base station 114 a, which may employ acellular-based radio technology, and with the base station 114 b, whichmay employ an IEEE 802 radio technology.

FIG. 1B is a system diagram of an example WTRU 102. As shown in FIG. 1B,the WTRU 102 may include a processor 118, a transceiver 120, atransmit/receive element 122, a speaker/microphone 124, a keypad 126, adisplay/touchpad 128, non-removable memory 106, removable memory 132, apower source 134, a global positioning system (GPS) chipset 136, andother peripherals 138. It will be appreciated that the WTRU 102 mayinclude any sub-combination of the foregoing elements while remainingconsistent with an embodiment.

The processor 118 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (DSP), aplurality of microprocessors, one or more microprocessors in associationwith a DSP core, a controller, a microcontroller, Application SpecificIntegrated Circuits (ASICs), Field Programmable Gate Array (FPGAs)circuits, any other type of integrated circuit (IC), a state machine,and the like. The processor 118 may perform signal coding, dataprocessing, power control, input/output processing, and/or any otherfunctionality that enables the WTRU 102 to operate in a wirelessenvironment. The processor 118 may be coupled to the transceiver 120,which may be coupled to the transmit/receive element 122. While FIG. 1Bdepicts the processor 118 and the transceiver 120 as separatecomponents, it will be appreciated that the processor 118 and thetransceiver 120 may be integrated together in an electronic package orchip.

The transmit/receive element 122 may be configured to transmit signalsto, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, thetransmit/receive element 122 may be an antenna configured to transmitand/or receive RF signals. In another embodiment, the transmit/receiveelement 122 may be an emitter/detector configured to transmit and/orreceive IR, ITV, or visible light signals, for example. In yet anotherembodiment, the transmit/receive element 122 may be configured totransmit and receive both RF and light signals. It will be appreciatedthat the transmit/receive element 122 may be configured to transmitand/or receive any combination of wireless signals.

In addition, although the transmit/receive element 122 is depicted inFIG. 1B as a single element, the WTRU 102 may include any number oftransmit/receive elements 122. More specifically, the WTRU 102 mayemploy MIMO technology. Thus, in one embodiment, the WTRU 102 mayinclude two or more transmit/receive elements 122 (e.g., multipleantennas) for transmitting and receiving wireless signals over the airinterface 116.

The transceiver 120 may be configured to modulate the signals that areto be transmitted by the transmit/receive element 122 and to demodulatethe signals that are received by the transmit/receive element 122. Asnoted above, the WTRU 102 may have multi-mode capabilities. Thus, thetransceiver 120 may include multiple transceivers for enabling the WTRU102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, forexample.

The processor 118 of the WTRU 102 may be coupled to, and may receiveuser input data from, the speaker/microphone 124, the keypad 126, and/orthe display/touchpad 128 (e.g., a liquid crystal display (LCD) displayunit or organic light-emitting diode (OLED) display unit). The processor118 may also output user data to the speaker/microphone 124, the keypad126, and/or the display/touchpad 128. In addition, the processor 118 mayaccess information from, and store data in, any type of suitable memory,such as the non-removable memory 106 and/or the removable memory 132.The non-removable memory 106 may include random-access memory (RAM),read-only memory (ROM), a hard disk, or any other type of memory storagedevice. The removable memory 132 may include a subscriber identitymodule (SIM) card, a memory stick, a secure digital (SD) memory card,and the like. In other embodiments, the processor 118 may accessinformation from, and store data in, memory that is not physicallylocated on the WTRU 102, such as on a server or a home computer (notshown).

The processor 118 may receive power from the power source 134, and maybe configured to distribute and/or control the power to the othercomponents in the WTRU 102. The power source 134 may be any suitabledevice for powering the WTRU 102. For example, the power source 134 mayinclude one or more dry cell batteries (e.g., nickel-cadmium (NiCd),nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion),etc.), solar cells, fuel cells, and the like.

The processor 118 may also be coupled to the GPS chipset 136, which maybe configured to provide location information (e.g., longitude andlatitude) regarding the current location of the WTRU 102. In additionto, or in lieu of, the information from the GPS chipset 136, the WTRU102 may receive location information over the air interface 116 from abase station (e.g., base stations 114 a, 114 b) and/or determine itslocation based on the timing of the signals being received from two ormore nearby base stations. It will be appreciated that the WTRU 102 mayacquire location information by way of any suitablelocation-determination method while remaining consistent with anembodiment.

The processor 118 may further be coupled to other peripherals 138, whichmay include one or more software and/or hardware modules that provideadditional features, functionality and/or wired or wirelessconnectivity. For example, the peripherals 138 may include anaccelerometer, an e-compass, a satellite transceiver, a digital camera(for photographs or video), a universal serial bus (USB) port, avibration device, a television transceiver, a hands free headset, aBluetooth® module, a frequency modulated (FM) radio unit, a digitalmusic player, a media player, a video game player module, an Internetbrowser, and the like.

FIG. 1C is a system diagram of the RAN 104 and the core network 106according to an embodiment. As noted above, the RAN 104 may employ anE-UTRA radio technology to communicate with the WTRUs 102 a, 102 b, 102c over the air interface 116. The RAN 104 may also be in communicationwith the core network 106.

The RAN 104 may include eNode-Bs 140 a, 140 b, 140 c, though it will beappreciated that the RAN 104 may include any number of eNode-Bs whileremaining consistent with an embodiment. The eNode-Bs 140 a, 140 b, 140c may each include one or more transceivers for communicating with theWTRUs 102 a, 102 b, 102 c over the air interface 116. In one embodiment,the eNode-Bs 140 a, 140 b, 140 c may implement MIMO technology. Thus,the eNode-B 140 a, for example, may use multiple antennas to transmitwireless signals to, and receive wireless signals from, the WTRU 102 a.

Each of the eNode-Bs 140 a, 140 b, 140 c may be associated with aparticular cell (not shown) and may be configured to handle radioresource management decisions, handover decisions, scheduling of usersin the uplink and/or downlink, and the like. As shown in FIG. 1C, theeNode-Bs 140 a, 140 b, 140 c may communicate with one another over an X2interface.

The core network 106 shown in FIG. 1C may include a mobility managementgateway (MME) 142, a serving gateway 144, and a packet data network(PDN) gateway 146. While each of the foregoing elements are depicted aspart of the core network 106, it will be appreciated that any one ofthese elements may be owned and/or operated by an entity other than thecore network operator.

The MME 142 may be connected to each of the eNode-Bs 142 a, 142 b, 142 cin the RAN 104 via an S1 interface and may serve as a control node. Forexample, the MME 142 may be responsible for authenticating users of theWTRUs 102 a, 102 b, 102 c, bearer activation/deactivation, selecting aparticular serving gateway during an initial attach of the WTRUs 102 a,102 b, 102 c, and the like. The MME 142 may also provide a control planefunction for switching between the RAN 104 and other RANs (not shown)that employ other radio technologies, such as GSM or WCDMA.

The serving gateway 144 may be connected to each of the eNode Bs 140 a,140 b, 140 c in the RAN 104 via the S1 interface. The serving gateway144 may generally route and forward user data packets to/from the WTRUs102 a, 102 b, 102 c. The serving gateway 144 may also perform otherfunctions, such as anchoring user planes during inter-eNode B handovers,triggering paging when downlink data is available for the WTRUs 102 a,102 b, 102 c, managing and storing contexts of the WTRUs 102 a, 102 b,102 c, and the like.

The serving gateway 144 may also be connected to the PDN gateway 146,which may provide the WTRUs 102 a, 102 b, 102 c with access topacket-switched networks, such as the Internet 110, to facilitatecommunications between the WTRUs 102 a, 102 b, 102 c and IP-enableddevices.

The core network 106 may facilitate communications with other networks.For example, the core network 106 may provide the WTRUs 102 a, 102 b,102 c with access to circuit-switched networks, such as the PSTN 108, tofacilitate communications between the WTRUs 102 a, 102 b, 102 c andtraditional land-line communications devices. For example, the corenetwork 106 may include, or may communicate with, an IP gateway (e.g.,an IP multimedia subsystem (IMS) server) that serves as an interfacebetween the core network 106 and the PSTN 108. In addition, the corenetwork 106 may provide the WTRUs 102 a, 102 b, 102 c with access to thenetworks 112, which may include other wired or wireless networks thatare owned and/or operated by other service providers.

FIG. 2A shows a WTRU 201 in an IMS session with a remote party 205. TheIMS session is conducted over the IMS network 210. The WTRU 201 may haveany number of ongoing media sessions with the remote party. For example,FIG. 2A shows an audio session 202 and a video session 203. Thesesessions are exemplary and other multimedia sessions may be used. TheIMS network 210 hosts IMS services and provides session and mediacontrol. It manages a WTRU's service interactions and establishes,monitors, supports and releases multimedia sessions.

Further, the WTRU 201 maintains IMS control signaling 204 with the IMSnetwork 210. The WTRU may use the IMS control signaling 204 to exercisesession control capabilities. IMS control signaling allows a WTRU toaccept or reject an incoming request for the establishment of a mediasession from a remote party. The WTRU 201 executes IMS control signalingon the control path 204. The IMS network 210 is on the recipient end ofthe WTRU's IMS control signaling 204.

FIG. 2B shows functional entities of an IMS network 210. The CallSession Control Function (CSCF) entity 213 sits on the path of IMScontrol signaling amongst WTRUs, remote parties, and other IMS networkentities. The CSCF entity may inspect the messaging of WTRUs, remoteparties, and other IMS network entities. The CSCF entity decides towhich application server (AS) control messaging is forwarded to providefor IMS services. The CSCF entity provides routing services and enforcesthe policies of network operators. The CSCF entity also handles WTRUregistrations.

The IMS network may use one or more ASs. The one or more ASs areconfigured to host and execute IMS services and to interface with theCSCF 213. Service Centralization and Continuity AS (SCC AS) 214 anchorsIMS sessions and enables service continuity for media sessions includingproviding for and executing the transfer of media sessions amongstWTRUs, combining and dividing media flows, and the addition of mediaflows. Aside from the SCC AS 214, other ASs, such as AS 215 shown inFIG. 2B, may interface with the CSCF 213 to provide for otherIMS-related services.

WTRU 201, as shown in FIG. 2B, has control signaling with the IMSnetwork 210, represented by control path 212. WTRU 201 may also have anynumber of IMS media sessions that are collectively represented by mediapath 211. FIG. 2B also shows access and remote legs for an IMS session.An access leg is a control leg between a WTRU and the SCC AS and aremote leg is a control leg between the SCC AS and a remote party.

Multiple WTRUs may be engaged in a single collaborative IMS session witha remote party through an IMS network. FIG. 2C shows multiple WTRUsserved by a single IMS network in a collaborative IMS session. In FIG.2C, WTRUs 201A-C (collectively hereinafter referred to by the numeralalone, WTRUs 201) are involved in a collaborative IMS session with aremote party (not shown). Each WTRU 201 has a control path 212A-C and amedia path 211A-C. The media paths 211 represent the ongoing mediasessions of the WTRUs 201. The control paths 212 represent the controlsignaling for the WTRUs 201.

While all of the WTRUs 201 are involved in a collaborative IMS session,one of the WTRUs 201 functions as a controller WTRU for thecollaborative session. In FIG. 2C, WTRU A 201A functions as thecontroller WTRU for the collaborative session. As a controller, WTRU A201A is able to execute Inter-Device Transfer (IDT) procedures by whichWTRU A 201A may add, transfer, duplicate, and remove media sessions onany WTRU 201 involved in the collaborative session. Furthermore, theservice profile of the controller WTRU in a collaborative session, suchas WTRU A 201A, may determine the services available on the pathsbetween the collaborative session and the remote party.

Although involved in a collaborative session with all WTRUs 201, theremote party may not be aware that one or more of its media sessions arewith controllee WTRUs, such as WTRU B 201B and WTRU C 201C. In acollaborative session, the remote party may only be aware of acontroller WTRU, WTRU A 201A. The controller WTRU A 201A uses controlpath 212A for collaborative session control messaging, as well as forcontrol signaling associated with its own media path 211. Within thecollaborative session, controllee WTRUs B 201B and C 201C are engaged inmedia sessions via media paths 211B-C, respectively. Controllee WTRUs B201B and C 201C also use control paths 212B-C for control signaling.

Within a collaborative session, controllee WTRUs are subordinate to thecontroller WTRU for IDT procedures. For example, a controller WTRU mayremove a media session from a controllee WTRU. Additionally, if acontrollee WTRU seeks to establish a media session, the controllee WTRUmay request such establishment from a controller WTRU and the controllerWTRU may accept or reject this request.

In FIG. 2C, Service Centralization and Continuity Application Server(SCC AS) 214 serves as an anchor SCC AS, that manages session controlsignaling between the WTRUs and the remote party. Furthermore, SCC AS214 enables service continuity for media sessions in the collaborativesession and provides for and executes IDT procedures. While in FIG. 2C,only one SCC AS serves the collaborative session, in other scenariosmultiple WTRUs in a collaborative session may each have their own SCC ASthat acts as a proxy to an anchor SCC AS. FIG. 2C also shows IMS networkentities CSCF 213 and AS 215.

Control signaling via a control path in an IMS session, as shown inFIGS. 2B-C, may utilize a signaling protocol such as Session InitiationProtocol (SIP). SIP, as known in the art, is a signaling protocol thatallows for establishing, modifying, terminating, adding, and duplicatingIMS multimedia sessions. SIP is a text-based protocol, where messagesmay take one of two forms: requests and responses. SIP requests includea REGISTER request, which may be used by a WTRU to register a PublicUser Identity (PUI) that is associated with the WTRU with the IMSnetwork. Other examples of SIP requests include an INVITE request, whichmay be used to establish a media session between a WTRU and a remoteparty, and ACK request, which may be used to confirm that a response hasbeen received. SIP response codes include a provisional response, i.e.,1xx, which may be used to indicate the request was received and is beingprocessed and a success response, i.e., 2xx, which may be use toindicate the action was successfully received and accepted.

SIP headers may be used by WTRUs and the IMS network that is utilizingSIP messaging. Some SIP headers include “To” (the address of theintended recipient), “From” (the address of the sender), and “Contact”(address information that identifies the resource requested or therequest originator, depending on whether it is a header for a request ora response).

In IMS, a WTRU may be registered in the IMS network using a Public UserIdentity (PUI). A PUI may be a SIP Uniform Resource Identifier (URI),such as an e-mail address, or a Tel URI, such as a telephone number. AnIMS network may contact a WTRU by addressing the WTRU's PUI. MultipleWTRUs may share the same PUI. For instance, an IMS subscriber may havemultiple WTRUs sharing the same PUI under one IMS subscription.

A WTRU may register its capabilities with the IMS network. A WTRU thatis capable of controlling a collaborative session may register as acollaborative session controller WTRU with the IMS network. Furthermore,a WTRU that is capable of media control may register as such. A mediacontroller WTRU, regardless of being a controller WTRU or a controlleeWTRU of a collaborative session, may have certain defined media controlprivileges within a collaborative session. A WTRU may update or changeits registered profile with the network at any time. To register itscapabilities, a WTRU may use a feature tag within an SIP Contact header.For instance, a WTRU seeking to register collaborative session controlcapabilities may use a feature tag such as g.3gpp.iut=“controller” and aWTRU seeking to register media control capabilities may use a featuretag such as g.3gpp.iut=“media-controller”. A WTRU may include thefeature tags indicating its IMS capabilities when utilizing the SIPREGISTER request to contact the IMS network.

The IMS network may maintain a profile of a WTRU's capabilities. Thisprofile may be influenced by the capabilities that the WTRU registeredwith the network or by other information within the network's knowledge.The network may rely upon the WTRU's registered capabilities orinformation within the service profile in providing IMS services, suchas media session routing or determining whether a WTRU is permitted toperform IMS actions. For instance, within an IMS network, an SCC AS thatis responsible for media session continuity may use registered WTRUcapabilities or profile information to influence media session routing.In the event that it receives an incoming media session request, an SCCAS may indicate to a CSCF a preference for the session to be routed to aregistered controller WTRU. A CSCF may then use this preference to routethe media session to the controller registered WTRU.

In SIP, an SCC AS may indicate routing preferences to a CSCF using IETFRFC 3841 headers and parameters. For instance, an SCC AS may add anAccept-Contact header field in an SIP request with a controller WTRUfeature tag and an “explicit” parameter, thereby requiring that therequest be routed to a WTRU registered with controller capabilities.Upon receiving the header field and controller feature tag in the SIPrequest, a CSCF routes the request to a WTRU with registered controllercapabilities. If no WTRUs have registered controller capabilities, therequest is routed to a WTRU that is not a registered controller. A SCCAS may also indicate routing preferences by adding an SIP Contact headerfield with a “require” parameter.

A WTRU may register a priority value with the IMS network. The priorityvalue may indicate to the IMS network a WTRU's priority in comparison toother WTRUs that may also be registered with the IMS network under thesame PUI. The priority value may also indicate to the IMS network theWTRU's preference level for receiving IMS sessions. A priority value maybe used by the IMS network in IMS management and providing IMS services,such as determining where to establish or route media sessions. A higherpriority value associated with a WTRU may indicate to the network agreater preference for the establishment and routing of media sessionsto that WTRU. For instance, if multiple WTRUs having the same PUI areregistered as controllers with the IMS network, the CSCF within the IMSnetwork may route an incoming media session to the WTRU with the higherpriority value. In one embodiment, a WTRU may register a priority valuewith the IMS network using the q-value parameter in the SIP Contactheader field.

FIG. 3 shows an information flow for WTRU registration and IMS sessionrouting in accordance with this embodiment. In FIG. 3, WTRU A 301, whichis IMS-capable, seeks to register its capabilities and a priority valuewith the IMS network. WTRU A 301A sends an SIP REGISTER request 310 toan IMS CSCF 313. The SIP REGISTER request 310 has a Contact header fieldthat includes both a feature tag indicating a capability of WTRU A 301and a q-value indicating a priority value associated with WTRU A 301A.In FIG. 3, the feature tag indicating controller capability of WTRU A301A is g.3gpp.controller=“controller” and the q-value indicating apriority value associated with WTRU A 301A is q=0.5.

CSCF 313 sends the SIP REGISTER request 310 to SCC AS 314 and CSCF 313sends an SIP 200 (OK) response 310 to WTRU A 301A. SCC AS 314 also sendsan SIP 200 (OK) response 310 to CSCF 313. As a result, WTRU A 301A hasregistered its capability and a priority value with the IMS network.WTRU B 301B and WTRU C 301C similarly register 320, 330 theircapabilities and associated priority values with the IMS network. WTRUsA-C 301A-C are registered under the same PUI with the IMS network. WTRUB 301B registers a feature tag indicating controller capability andq-value of q=0.8, while WTRU C 301C registers no feature tag indicatingcontrol capability, but registers a q-value of q=0.5.

CSCF 313 receives an SIP INVITE request 340 from a remote party (notshown) for a media session. The SIP INVITE request 340 is addressed tothe PUI shared by WTRUs A-C 301A-C. CSCF 313 sends the SIP INVITErequest 340 to SCC AS 314. SCC AS 314 prefers that the SIP INVITErequest be routed to a controller WTRU. SCC AS 314 uses RFC 3841procedures and adds an Accept-Contact 345 with a controller feature tagto indicate this preference in the SIP INVITE request. SCC AS 314 sendsthe SIP INVITE request 350 to CSCF 313.

WTRU A 301A and WTRU B 301B have controller capabilities, while WTRU C301C does not have such capabilities. CSCF 313 may therefore send theSIP INVITE request to either WTRU A 301A or WTRU B 301B, but not WTRU C301C. WTRU B 301B has a higher associated q-value than WTRU A 301A, soCSCF 313 determines that the SIP INVITE request is directed to thecontroller WTRU with the higher q-value 355 and then sends the SIPINVITE request 360 to WTRU B 301B. Rather than forking, i.e., sendingthe SIP INVITE request to both WTRU A 301A and WTRU B 301B, the CSCF 313sends the SIP INVITE request to WTRU B 301B.

Multiple SCC ASs may be involved in an IMS session, with each SCC ASserving one WTRU or multiple WTRUs. This may be the case where multipleWTRUs are involved in a collaborative IMS session and the WTRUs areserved by multiple SCC ASs. For example, one SCC AS may be an anchor SCCAS for the collaborative session, and the remaining SCC ASs may proxymessages for the anchor SCC AS.

The WTRUs involved in an IMS session may have different SCC ASs becausethe WTRUs are under different IMS subscriptions or are served bydifferent IMS networks. The SCC AS serving the WTRU that initiated theIMS session may function as an anchor SCC AS until the anchor point istransferred to another SCC AS. The initiating WTRU may have involvedother WTRUs in the IMS session (for example, by transferring,duplicating, or establishing IMS media sessions to these WTRUs). The SCCASs serving the other WTRUs may, therefore, act as proxies to the SCC ASof the initiating WTRU.

FIG. 4 shows multiple WTRUs served by multiple IMS networks in an IMScollaborative session. WTRUs 401A-C (collectively hereinafter referredto by the numeral alone, WTRUs 401) are each served by SCC AS 402A-C,respectively, within their respective IMS networks. SCC AS A 402A is theanchor whose policies govern the IMS session. Further, the anchor SCC ASA 402A enables service continuity for media sessions amongst all WTRUs401. SCC AS B 402B and SCC AS C 402C serve WTRU B 401B and WTRU C 402C,respectively, where WTRU B 402B and WTRU C 402C may belong to differentIMS subscriptions. In a collaborative session anchored at SCC AS A 402A,SCC AS B 402B and SCC AS C 402C as act proxies for messages between WTRUB 401B and WTRU C 401C, respectively, and SCC AS A 402A.

In FIG. 4, an access leg 407 is presented to anchor SCC AS A 402A and aremote leg 408 is presented to SCC AS A 402A from a remote party (notshown). WTRUs 401 each have a control path 405 with their respective SCCASs 402 and a media path 406 with the remote party. Furthermore, each ofthe IMS networks has a CSCF 403A-C.

An SCC AS may use control signaling to identify itself as an anchor toother SCC ASs. Additionally, an anchor SCC AS may transfer the anchorpoint from itself to another SCC AS via control signaling or anon-anchor SCC AS may request the transfer of the anchor point from ananchor SCC AS via control signaling.

Signaling between SCC ASs may be dedicated for the purposes of anchoridentification and transfer or the signaling may be incorporated orcontained within IMS signaling. For instance, an anchor SCC AS mayidentify itself as such by incorporating control signaling to thateffect within an IMS control message that was routed through anon-anchor SCC AS but was intended for a WTRU served by the non-anchorSCC AS. Thereby, a non-anchor SCC AS routing a message to the WTRU it isserving may be informed of the identity of the anchor SCC AS via themessage. A non-anchor may remove the signaling incorporated in themessage and pass the message to its intended party, the WTRU. As aresult, this anchor signaling may in a sense “ride” conventional IMSsignaling.

For security purposes, it may be preferable that only SCC ASs within IMSnetworks be aware of the anchor SCC AS. Accordingly, signaling for thepurpose of anchor identification and transfer that is incorporated inIMS signaling may be removed by the SCC AS recipient before the IMSsignaling is passed along to WTRUs.

An SIP header may be utilized by SCC ASs to identify an anchor SCC ASand to transfer the anchor from one SCC AS to another SCC AS. A privateheader, or a P-Header, is one example of an SIP header field that may beutilized for these purposes. A P-Header labeled as P-Anchor-Point-ID maybe used to identify an anchor point. For instance, P-Anchor-Point-ID:sccas1@example.com may be used to identify an anchor SCC AS by itsaddress, sccas1@example.com, whereby, an anchor SCC AS may insert thisheader field in IMS SIP signaling to identify itself as an anchor SCC ASto other SCC ASs. Particularly, within a trusted network or domain,where it is unlikely that an SCC AS who is not an anchor will identifyitself as such.

In another embodiment, an SCC AS may request anchor transfer by changingthe P-Anchor-Point-ID address from the address of the current anchor SCCAS to the address of the SCC AS to which anchor point transfer issought.

Parameters may be added to this header for transferring the SCC ASanchor. For example, transfer-anchor-point-to may be used by an anchorSCC AS to transfer the anchor point to another SCC AS identified by theparameter. For example, the P-Header P-Anchor-Point-ID:sccas1@example.com; transfer-anchor-to: sccas2@example.com may beinserted by an SCC AS in an SIP message to identify itself as an anchorpoint and to request transfer of the anchor point to another SCC AS(identified by its address, sccas2@example.com).

In another embodiment, a header field utilized for the purpose of anchoridentification or transfer may comprise multiple parameters. Aninserted-by parameter may identify the SCC AS that inserted the headerin the SIP message. An Action parameter may allow an SCC AS to notifyother SCC ASs of the purpose of the header field. The Action headerfield may identify the anchor point, request anchor transfer to anotherSCC AS, request anchor transfer from the anchor SCC AS to another SCCAS, or reject a requested anchor transfer. Table 1 shows instances ofAction parameter fields and their associated meanings.

TABLE 1 Action parameter fields Action Accompanied parameter Purpose by:anchor-point Identifies the anchor request-anchor Request anchortransfer request-To* from an anchor SCC AS transfer-anchor Requestanchor transfer request-To* to another SCC AS reject-anchor Reject therequest of anchor transfer *Identifies SCC AS the request is addressedto

Accordingly, if an anchor SCC AS with the address sccas1@example.comseeks to transfer the anchor point to another SCC AS with the addresssccas2@example.com, the anchor SCC AS may utilize the headerP-Anchor-Point-ID: inserted-by: sccas1@example.com Action:transfer-anchor request-to: sccas2@example.com. Then, if the non-anchorSCC AS with the address sccas2@example.com accepts the anchor pointtransfer, the non-anchor SCC AS may respond by utilizing the headerP-Anchor-Point-ID: Inserted-by: sccas2@example.com Action: anchor-point.Alternatively, if the non-anchor SCC AS rejects the anchor pointtransfer, it may respond by utilizing the header P-Anchor-Point-ID:Inserted-by: sccas2@example.com Action: reject-anchor.

FIG. 5 shows an information flow for anchor SCC AS identification andtransferring in accordance with this embodiment. In FIG. 5, SCC AS A502A is an anchor SCC AS 505 for an ongoing IMS session, whereas SCC ASB 502B and SSC AS C 502C are non-anchors. Each SCC AS 502A-C may serveIMS-capable WTRUs (not shown), with SCC AS B 502B and SCC AS C 502Cacting as proxies for the IMS signaling between their respective WTRUsand anchor SCC AS A 502A. The WTRUs, which belong to different IMSnetworks, may be involved in a collaborative IMS session. SCC AS A 502Aidentifies itself as an anchor by including an SIP header in an SIPmessage to SCC AS B 502B 510. This SIP header may be part of an SIPmessage sent solely to convey this anchor information, or,alternatively, the header may simply be incorporated into an SIP messageintended for a party other than SCC AS B 502B. For instance, the headermay be included in an SIP message to the WTRU served by SCC AS B 502B.When it receives the message, SCC AS B 502B may then remove the headerinformation and, in its role as a proxy, convey the remainder of the SIPmessage to the WTRU it is serving.

SCC AS A 502A requests to transfer the anchor point to SCC AS B 502B byincluding an SIP header in an SIP message to SCC AS B 502B 520. SCC AS B502B accepts the anchor point transfer by including an SIP header in anSIP message to SCC AS A 502A 530. Thereby, SCC AS B 502B becomes theanchor SCC AS 535. SCC AS C 502C then requests that the anchor point betransferred to itself from SCC AS B 502B by including an SIP header inan SIP message to SCC AS B 502B 540. SCC AS B 502B does not wish torelinquish the anchor point so it rejects the anchor point transferrequest by including an SIP header in an SIP message to SCC AS C 502B550, whereby SCC AS B 502B remains the anchor SCC AS 555.

In another embodiment, an SIP XML body may be utilized for anchoridentification and transfer. An anchor SCC AS may identify itself assuch to other SCC ASs by utilizing an XML body. An SCC AS may alsoinclude the type of action an SCC AS seeks to carry out, such asmaintaining the anchor point or requesting anchor point transfer.Additionally, the XML body may include the identity of the SCC AS towhich anchor point transfer is desired or the identity of a non-anchorSCC AS seeking anchor transfer.

In another embodiment, an SCC AS may identify itself as an anchor SCC ASby including its address in a Call-Info header of an SIP message, suchas Call-Info: sccas1@example.com; purpose=anchor. In another embodiment,an anchor SCC AS may identify itself as such in a Record-Route header.For instance, it may add a parameter, e.g. “anchor-point”, to itsaddress in the Record-Route header of an SIP message. For exampleRecord-Route: sccas1@example.com;anchor-point identifies SCC AS with theaddress sccas1@example.com as an anchor point.

In an IMS collaborative session, session control is maintained by acontroller WTRU, while other WTRUs who are involved in the collaborativesession are controllee WTRUs. A controller WTRU may identify itself as acollaborative session controller to an IMS network or other WTRUs thatare involved in a collaborative session. Furthermore, a controller WTRUmay transfer collaborative session control to another WTRU, making theWTRU receiving collaborative session control the new controller WTRU.

In an IMS network, SIP signaling may be used to indicate the identity ofa collaborative session controller WTRU. Furthermore, SIP controlsignaling may be used to transfer collaborative session control. An SIPXML body may comprise information elements indicating the controllerWTRU for a collaborative session. Additionally, the XML body may be usedin IMS control signaling for the purpose of transferring collaborativesession control from one WTRU to another WTRU. For instance, acontroller WTRU may use an SIP XML body to request that another WTRUassume collaborative session control. Collaborative session control maybe accepted or rejected and the WTRU accepting or rejecting the transferof collaborative session control may indicate so in an SIP XML body.Furthermore, a controllee WTRU may use an SIP XML body to request thatcollaborative session control be transferred to it from a controllerWTRU.

In another embodiment, a controller WTRU in a collaborative session mayinclude a parameter in the SIP Contact header field indicating whetherit seeks to retain or transfer collaborative session control. Forexample, the presence of the parameter “controller” in the Contactheader field informs the SCC AS and the IMS network that the WTRU seeksto maintain collaborative session control.

In another embodiment, a P-Header may be used for transferringcollaborative session control. The P-Header may have a Controllerparameter that identifies the collaborative session controller. It mayalso have an Action parameter that indicates a request by the controllerWTRU to transfer collaborative session control to another WTRU or arequest by a controllee WTRU to obtain collaborative session controlfrom the controller WTRU. The P-Header may also have a parameter toindicate the WTRU to which the Action parameter relates. For instance,the SIP header P-Session-Control: Controller=wtruA@example.com;Action=transfer; Request-to=wtruB@example.com may be included by WTRU Ain an SIP message such as REFER or Re-INVITE to request transfer ofcollaborative session control to WTRU B. WTRU B may either accept orreject this request by including an SIP header in an SIP message to WTRUA.

In another embodiment, collaborative session control may be transferredby changing the contact address that the IMS network affiliates with thecontroller WTRU. In this embodiment, if the IMS network was previouslyreceiving IMS signaling with a contact address for one controller WTRU,collaborative session control transfer may be indicated by the IMSnetwork receiving IMS signaling with a contact address for anothercontroller WTRU, where both WTRUs are in a collaborative session. Thechange of contact address may be indicated together with the“controller” feature tag, which indicates that a device has controllercapabilities. The presence of the feature tag in requests means a WTRUis the controller, while the absence of the feature tag means anotherWTRU with controller capabilities may take control of the collaborativesession. Accordingly, the presence or absence of the controller featuretag may prompt the SCC AS to change the contact address that the IMSnetwork identifies as the contact address for the controller WTRU.

FIG. 6 shows an information flow for the transfer of IMS collaborativesession control. In FIG. 6, WTRU A 601A and WTRU B 601B are engaged in acollaborative session with a remote party 605. SCC AS A 602A serves WTRUA 601A and SCC AS B 602B serves WTRU B 601B. For this collaborativesession, WTRU A 601A maintains collaborative session control. WTRU A601A is a controller WTRU, WTRU B 601B is a controllee WTRU, and SCC ASA 602A is the anchor SCC AS for the collaborative session 610. Each WTRU601A-B has a media flow with the remote party 605 520.

As a controller WTRU, WTRU A 601A maintains collaborative sessioncontrol signaling with SCC AS A 602A and the remote party 605 630. WTRUA 601A seeks to transfer collaborative session control to WTRU B 601B.WTRU A 601A sends an SIP request to WTRU B 601B to transfercollaborative session control, in accordance with the embodimentsdescribed herein 640. WTRU B 601B accepts transfer of collaborativesession control and sends an SIP message to WTRU A 601A indicating itsacceptance of collaborative session control, in accordance with theembodiments described herein 650. Thereby, WTRU B 601B becomes thecontroller WTRU and WTRU A 601A becomes the controllee WTRU for thecollaborative session 660. As a controller WTRU, WTRU B 601B maintainscollaborative session control signaling with SCC AS A 602A and theremote party 605 670, where SCC AS A 602A acts as an anchor SCC AS andSCC AS B 602B proxies the messaging between WTRU B 601B and SCC AS A602A.

Although features and elements are described above in particularcombinations, one of ordinary skill in the art will appreciate that eachfeature or element can be used alone or in any combination with theother features and elements. In addition, the methods described hereinmay be implemented in a computer program, software, or firmwareincorporated in a computer-readable medium for execution by a computeror processor. Examples of computer-readable media include electronicsignals (transmitted over wired or wireless connections) andcomputer-readable storage media. Examples of computer-readable storagemedia include, but are not limited to, a read only memory (ROM), arandom access memory (RAM), a register, cache memory, semiconductormemory devices, magnetic media such as internal hard disks and removabledisks, magneto-optical media, and optical media such as CD-ROM disks,and digital versatile disks (DVDs). A processor in association withsoftware may be used to implement a radio frequency transceiver for usein a WTRU, UE, terminal, base station, RNC, or any host computer.

1. A method, implemented for use in an Internet Protocol (IP) MultimediaSubsystem (IMS) capable wireless transmit/receive unit (WTRU), themethod comprising: registering an IMS service priority with an IMSnetwork, wherein the IMS service priority indicates the WTRU's priorityin receiving IMS services; and receiving an IMS service from the IMSnetwork based on the WTRU's IMS service priority.
 2. The method as inclaim 1, wherein IMS service priority is indicated using a priorityvalue.
 3. The method as in claim 1 wherein the WTRU uses SessionInitiation Protocol (SIP) messaging to signal with the IMS network. 4.The method as in claim 2 wherein the WTRU registers the service priorityvalue using a q-value parameter in an SIP Contact field header.
 5. Themethod as in claim 1, further comprising: registering a public useridentity with the IMS network, wherein the public user identity isshared with other IMS-capable WTRUs.
 6. The method as in claim 1,further comprising: registering an IMS service capability with the IMSnetwork, wherein the IMS service capability indicates the WTRU'scapability to perform specific IMS functions; and receiving IMS servicefrom the IMS network based on the WTRU's IMS service capability.
 7. Themethod as in claim 6 wherein the WTRU registers IMS service capabilityusing an SIP Contact field header feature tag.
 8. The method as in claim6 wherein the WTRU registers a controller capability with the IMSnetwork.
 9. A wireless transmit/receive unit (WTRU) for requestingtransfer of Internet Protocol (IP) multimedia subsystem (IMS)collaborative session control, comprising: a processor configured togenerate a collaborative session control transfer request for requestingthe transfer of control of an Internet Protocol (IP) multimediasubsystem (IMS) collaborative session, wherein the request is carried inan Extensible Markup Language (XML) body of an Session InitiationProtocol (SIP) message; a transmitter, in communication with theprocessor, configured to transmit the SIP message requestingcollaborative session control transfer to an IMS network.
 10. The WTRUas in claim 9 further comprising: a receiver, a receiver incommunication with the processor, configured to receive a collaborativesession control transfer response indicating that collaborative sessioncontrol is transferred, wherein the response in carried in an SIPmessage.
 11. The WTRU as in claim 9, wherein the WTRU is participatingin an IMS collaborative session with a remote party.
 12. The WTRU as inclaim 9, wherein the XML body of the SIP request for collaborativesession control transfer includes one or more of an identity of acollaborative session controller WTRU, an identity of the WTRUrequesting collaborative session control transfer, or an identity of aWTRU to which collaborative session control is requested to betransferred.
 13. The WTRU as in claim 10, wherein the collaborativesession control transfer response is carried in an XML body of an SIPmessage.
 14. A method, implemented by an anchor Application Server (AS)for enabling service continuity in an Internet Protocol (IP) MultimediaSubsystem (IMS) network, the method comprising: requesting a second ASto assume an anchor role for an IMS session, wherein the request isindicated in an SIP message; and relinquishing anchor role for the IMSsession to the second AS.
 15. The method as in claim 14 wherein the ASidentifies itself as an anchor AS to the second AS in a private headerof an SIP message.
 16. The method as in claim 14 wherein the AS requeststransfer of the anchor role to the second AS in a parameter of an SIPprivate header.
 17. The method as in claim 14, further comprising:receiving an answer from the second AS, wherein the answer indicatesthat the second AS accepts the anchor role or that the second AS rejectsthe anchor role.
 18. The method as in claim 14 wherein the AS requeststransfer of the anchor role to the second AS in an Extensible MarkupLanguage (XML) body of an SIP message.
 19. The method as in claim 14wherein the second AS serves an IMS-capable device and proxies messagesfrom the IMS-capable device to anchor AS.
 20. The method as in claim 19wherein the IMS-capable device is involved in an IMS collaborativesession anchored at the AS.